Current service providing network systems, such as the IP Multimedia Subsystem as developed by the Third Generation Partnership Project (3GPP), are designed to provide IP Multimedia over mobile communication networks (3GPP TS 22.228, TS 23.218, TS 23.228, TS 24.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329). For fixed broadband services, such as Voice over IP (VoIP), the ETSI TISPAN working group is further developing IMS (TS 29.229: IP Multimedia Call Control Protocol based on SIP and SD).
Within the IMS architecture the basic end-user subscription functions and the IP session management are decoupled from the specific VoIP service functions, e.g. number analysis, CLIP/R, Call Waiting, Call Barring, Call Waiting, etc. These services are handled within one or more application servers which reside in the network. IMS, which makes use of the Session Initiation Protocol (SIP) to set up and control client-to-client call services and client-to-server call services, provides the delivery of reliable VoIP services which meet the requirements regarding Quality of Services (QoS) and the regulatory demands for routing, privacy, security and legal interception.
FIG. 1 is a schematic of the registration process of a user terminal (EU) 102 comprising a SIP client (SIP AU) 104 to an exemplary IMS system 100. The core of the IMS may be formed by a set of Call/Session Control Functions (CSCF) comprising amongst others an Proxy-CSCF (P-CSCF) 106, an Interrogating-CSCF (I-CSCF) 108 and an Serving-CSCF (S-CSCF) 110. These functions may perform different tasks within the IMS core.
The P-CSCF 106 is the first contact within the IMS core and routes a SIP message (e.g. SIP INVITE) to the S-CSCF of a user. The P-CSCF may obtain its routing information during the registration to the IMS system. The I-CSCF 108 is located at the edge of a domain and identifies the correct S-CSCF for each incoming SIP request and forwards the request to that S-CSCF via an P-CSCF. Its IP address is published in the DNS of the domain so that remote servers can find it. The S-CSCF 110 performs the session control services on the basis of the service profile of the user. It may also act as a SIP registrar thus forming an important component for accessing and billing of IMS services.
The service profile stored in the Home Subscriber Service (HSS) 114 may contain service routing information thus determining the routing of SIP messages that are either originated from or addressed to a particular client or server. The user service profile is transferred to the S-CSCF over Cx in a standardized XML format.
The registration process as depicted in FIG. 1 may be initiated by the first user terminal (UE) sending a SIP REGISTER message via a Session Border Controller (SBC) 112 and the P-CSCF to the I-CSCF (step 1). The SBC may be used to control the data streams within one or more call session, e.g. signaling streams controlling the call, and one or more media streams which carry the call's audio, video, or other data along with information concerning how that data is flowing across the network. The I-CSCF may assign a S-SCSC to the UE by requesting information related to the user registration status from the HSS (step 2). The HSS provides the S-CSCF the required information in order for the I-CSCF to select a suitable S-CSCF. The I-CSCF then forwards the REGISTER message to the selected S-CSCF (step 3). The S-CSCF thereafter authenticates the user and informs the HSS—after successful authentication—that the user is registered (step 4). In return, the HSS provides the S-CSCF with the service profile of the user (step 5). On the basis of the information in the user service profile, the S-CSCF then may register the user with one or more application servers by sending a REGISTER message to the application servers 116 identified by a set of initial Filter Criteria (iFC). These iFC's may be contained in the user service profile or in a separate database (step 6). This way each application server may receive specific user configuration information which is needed for delivering a service hosted on the application server to the user.
An iFC may comprise information which determines whether or not a SIP message should be routed to a service located in a particular application server. The iFC may be defined in the standard in paragraph B.2.2 of document TS 129 228, which is hereby incorporated by reference in this application. An iFC may comprise a Trigger Point, i.e. a Boolean flag determined by a set of conditions and the SIP URI of an application server the SIP request should be routed to in case a received SIP message fulfils the condition(s) set by the Trigger point (Trigger point is TRUE), In case the Trigger Point is FALSE, the SIP message will not be routed to the application server comprising the service identified in the iFC. One or more Trigger Points are also referred to as trigger point information.
FIG. 2 provides a schematic of a VoIP call session (after registration) involving an originating call service (number normalization). A first user terminal UE-A and second user terminal UE-B (202,204) may be registered to a first IMS core and second IMS core respectively (206,208). Each user terminal may comprise a SIP client and has an associated S-CSCF (210,212), which is registered to one or more applications servers (214,216).
The call session may be initiated by the first user terminal UE-A 202 sending an SIP INVITE to the second user terminal UE-B 204. The SIP INVITE is routed via the SBC and the P-CSCF to the S-CSCF serving UE-A (step 1). The header of the SIP message may contain the requested URI (R-URI) of the called party UE-B at the terminating side.
Thereafter the S-CSCF of UE-A may execute the service profile of UE-A containing a set of services to which UE-A is subscribed to and which determines which services in the one or more application servers should be “included” during the establishment of the SIP session. In this case the SIP message is routed to a VoIP service: number normalization service, which transforms the local number 3434343 into a normalized number +31703434343 format (step 2). Hence, the normalization service replaces the original R-URI: 3434343 in the SIP header section by a modified R-URI: +31703434343 comprising the normalized telephone number (step 3).
The modified R-URI may be resolved using ENUM and DNS 218 in an URI of an I-CSCF of the IMS network of UE-B (step 4). Thereafter, the I-CSCF forwards the SIP message on the basis of the information retrieved from the HSS to the S-CSCF serving UE-B (step 6). The S-CSCF of UE-B may execute (in a similar way as described above in relation with the S-CSCF serving UE-A) the service profile of UE-B comprising a list of iFCs corresponding to a set of services, which UE-B is subscribed to. Depending on the service profile, the S-CSCF may route the SIP message via an application server in which a number of VoIP call services are located, to UE-B. Alternatively, the service in the application server may be a terminating service acting as an endpoint for the SIP request or an intermediate (forwarding) service, e.g. Call Forwarding, wherein the S-CSCF routes the SIP message to yet another (third) user terminal UE-C.
Although IMS enables a large amount of multimedia services, it also has disadvantages, especially within the context of VoIP. Within the IMS standard, VoIP is only described in combination with the use of application servers in the network. The application servers hosting the VoIP services however may require configuration data for each service. Further, the basic call flow in FIG. 2, clearly illustrates that the establishment of a call session requires a substantial amount of SIP messaging to be exchanged between the various clients and servers involved. Moreover, the capacity of the application servers is dependent on the number of subscribers to the services, while the capacity of IMS system scales with the volume of data traffic. Hence, the dimensioning of the network resources in such conventional IMS system is complex and based on forecasts of the VoIP service behavior of the users is needed. In addition an operator may want to differentiate between subscribers that do not wish to use (all) the VoIP services provided via IMS application services, for example because their terminals have these capabilities, and those that do want the VoIP services. It may even be beneficial to be able to offer different subscriptions depending on the amount of network services a user (identity) is subscribed to.